home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc725.txt < prev    next >
Text File  |  1994-08-01  |  44KB  |  1,580 lines

  1. NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
  2. An RJE Protocol for a Resource Sharing Network
  3.  
  4.  
  5.  
  6.                     CAC Technical Memorandum No. 86
  7.  
  8.                            CCTC-WAD No. 7508
  9.  
  10.                           ARPANET RFC No. 725
  11.  
  12.                              NIC No. 38316
  13.  
  14.              An RJE Protocol for a Resource Sharing Network
  15.  
  16.                                    by
  17.  
  18.                                 John Day
  19.  
  20.                             Gary R. Grossman
  21.  
  22.                             Prepared for the
  23.  
  24.                   Command and Control Technical Center
  25.  
  26.                          WWMCCS ADP Directorate
  27.  
  28.                                  of the
  29.  
  30.                      Defense Communications Agency
  31.  
  32.                          Washington, D.C. 20305
  33.  
  34.                              under contract
  35.  
  36.                             DCAl00-76-C-0088
  37.  
  38.                     Center for Advanced Computation
  39.  
  40.                University of Illinois at Urbana-Champaign
  41.  
  42.                          Urbana, Illinois 61801
  43.  
  44.                              March 1, 1977
  45.  
  46.     Approved for Release - Peter A. Alsberg, Principal Investigator
  47.  
  48. NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
  49. An RJE Protocol for a Resource Sharing Network
  50.  
  51.  
  52.  
  53. For many users of the ARPANET, an RJE protocol is probably as important
  54. in terms of utility as a TELNET (VTP) protocol.  In fact, the facilities
  55. provided by a TELNET and an RJE protocol are probably of most interest
  56. to most users of computer networks.  For these users, the net provides a
  57. fast, cheap RJE surrogate, just as TELNET provides a telephone surrogate
  58. for the timesharing user.  The collection (and layers) of protocols that
  59. provide these services must be organized to efficiently support a wide
  60. variety of applications and user needs.  They should not pose an undue
  61. software burden on the user.
  62.  
  63. The "official" NETRJE protocol for the ARPANET has met an underwhelming
  64. response from both the user and server community.  I believe there are
  65. two basic reasons.  First, a large commitment of resources is necessary
  66. to implement NETRJE.  Second, the protocol creates serious security
  67. problems.
  68.  
  69. In order to support the ARPA RJE protocol, a user must implement User
  70. Telnet, Server FTP, and User RJE, while a server must implement Server
  71. Telnet, User FTP, and Server RJE.  In addition when an RJE session is
  72. going on all three of these protocol implementations will be executing
  73. for most of the life of the session.  This could entail considerable
  74. burden for some systems.  Although it may not be out of line to require
  75. a service to shoulder such burdens, it is out of line to require a user
  76. to assume them in order to gain a rather basic service.  Most user
  77. installations are oriented toward meeting their user's needs not toward
  78. implementing large amounts of network software.  (In fact one of the
  79. better aspects of the previous ARPANET protocol designs was that they
  80. attempted to minimize the work for the user.  (It must be admitted
  81. though that compassion for the user was not the reason for this
  82. approach.)
  83.  
  84. In order to support a "hot line printer" (i.e., a job is automatically
  85. printed when it is completed), the user must store his user code and
  86. password for the output host at the server host.  This, of course,
  87. presents a rather severe security problem.  Although the ARPANET can not
  88. be made totally secure without massive revision, there are some basic
  89. precautions that can be taken to protect users from being victimized by
  90. every first year Computer Science student with access to the net.
  91.  
  92. The RJE protocol proposed here tries to mitigate the implementation
  93. problems and security problems.  The protocol is designed to provide
  94. three levels of service.  A user or server has the perogative to
  95. implement the protocol at whatever level their resources allow.  The
  96. service can then be upgraded to cleaner or more sophisticated approaches
  97. when and if the opportunity arises.
  98.  
  99. This protocol is described in terms of the ARPANET.  Several aspects of
  100.  
  101.  
  102.  
  103.  
  104.  
  105.                                                                 [page 1]
  106.  
  107. NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
  108. An RJE Protocol for a Resource Sharing Network
  109.  
  110.  
  111.  
  112. the design (such as the reply structure) were made to coincide with
  113. existing ARPANET conventions.  This was done to facilitate understanding
  114. and limit the discussion to the protocol itself.  Although the protocol
  115. is described in ARPANET terms, it should be applicable to other network
  116. environments.
  117.  
  118. This paper is not considered to be complete in every detail.  It was
  119. written primarily to elicit comments from the network community and to
  120. measure the desire of the community to adopt such a procedure.  We have
  121. tried to describe enough of the protocol so that the reader can get an
  122. idea of how things are to work without getting bogged down in the detail
  123. that would be necessary for implementation.  Below is an outline of the
  124. final protocol document as presently conceived.  Sections marked with an
  125. asterisk are to be provided later.
  126.  
  127.  
  128.  
  129.  
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136.  
  137.  
  138.  
  139.  
  140.  
  141.  
  142.  
  143.  
  144.  
  145.  
  146.  
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.                                                                 [page 2]
  165.  
  166. NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
  167. An RJE Protocol for a Resource Sharing Network
  168.  
  169.  
  170.  
  171. Introduction
  172.  
  173. Part I
  174.  
  175.    The NETRJE Models
  176.  
  177.       1.  Telnet (VTP) Model
  178.  
  179.       2.  Telnet with Data Transfer Model
  180.  
  181.       3.  Telnet with FTP Model
  182.  
  183.    Scenarios for the Models
  184.  
  185. *    Suggested Implementaton Schemes for Various Applications
  186.  
  187. Part II
  188.  
  189.    The Server RJE Commands
  190.  
  191. *        General Conventions
  192.  
  193.    Commands
  194.  
  195.    Replies
  196.  
  197.       Numerical List
  198.  
  199.       Command-Reply List
  200.  
  201. *         Details of the Data Transfer
  202.  
  203. *         Minimal Requirements for a User RJE
  204.  
  205. *         Minimal Requirements for a Server RJE
  206.  
  207. *         Glossary of Terms
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.                                                                 [page 3]
  224.  
  225. NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
  226. An RJE Protocol for a Resource Sharing Network
  227.  
  228.  
  229.  
  230. Part I THE NETRJE MODELS
  231. ------------------------
  232.  
  233. This section describes the proposed NETRJE protocol in a narrative form.
  234. A formal definition will be included in Part II after review.  The
  235. narrative should provide the general reader with the flavor of the
  236. protocol without getting bogged down in unnecessary detail.  The
  237. proposed NETRJE protocol provides three different models for job
  238. submission and retrieval.  The three models can be characterized as 1)
  239. RJE using Telnet only, 2) RJE using Telnet and Data Transfer, and 3) RJE
  240. using FTP.  This approach provides flexibility for both implementors and
  241. users.  User and server sites constrained by manpower or machine
  242. resources may implement only the simpler models.  The user may use the
  243. different models separately or in any consistent combination which best
  244. suits his requirements and convenience.  Servers should assume that the
  245. minimal implementation of a more sophisticated model includes the
  246. minimal implementations of all less sophisticated models.  (There are,
  247. however, certain minimal requirements that must be supported.)  This
  248. secton will discuss each of these models in turn, and show each one can
  249. be used to provide a useful network RJE functon.
  250.  
  251. This protocol does not contain the security difficulties of the present
  252. protocol.  This has been avoided by requiring that the burden of
  253. implementing the "hot line printer" or "hot card reader" be put on the
  254. user system.  Thus, those systems which desire such a facility may still
  255. support it.  The user implementaton will be slightly more complicated.
  256. The trade-off is the increased security of the protocol.
  257.  
  258. End-to-end protocols are assumed to be available and to provide an
  259. ordered, error free bit stream to the RJE protocol.  It is also assumed
  260. that a suitable virtual terminal protocol such as Telnet, is used to
  261. format the control connection.
  262.  
  263. RJE Using Only Telnet (VTP)
  264. ---------------------------
  265.  
  266. The intent of this model is, bluntly, to provide an official "quick and
  267. dirty" form of the protocol.  Many organizatons, both users and servers,
  268. are often confronted with problem of providing a service quickly or
  269. within very tight budgetary constraints.  This model is intended for
  270. these situations.  With this model, the user is required only to be able
  271. to establish a Telnet connection via the RJE contact socket.  Commands,
  272. replies, and data are all sent over the Telnet connecton.  Card input or
  273. printer output has the appearance of coming from or going to the user's
  274. terminal.  The user's system may allow output to be diverted from the
  275. terminal to another device such as the line printer.  The technique of
  276. diverting terminal output was used with great success in the MARK I ANTS
  277.  
  278.  
  279.  
  280.  
  281.  
  282.                                                                 [page 4]
  283.  
  284. NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
  285. An RJE Protocol for a Resource Sharing Network
  286.  
  287.  
  288.  
  289. systems where various devices were not assigned socket numbers as in a
  290. TIP.  This technique is also useful for hosts that allow program access
  291. to the network only through the user's Telnet connection.  This
  292. situation may exist in the early phases of a server's availability to
  293. the network.  When data is transferred in this mode an end-of-data
  294. marker will be sent to aid the receiving host in determining when to
  295. stop diverting the data.  This model will have to handle the problems of
  296. data traveling on a connection essentially meant for control.  The use
  297. of this data transfer mechanism is intended as an intermediate measure
  298. required by limited resources.  For now we let it stand that the
  299. designers are aware of the problems inherent in embedding commands or
  300. replies in the data stream.  We will leave the exact resolution of the
  301. problem to the formal definition.
  302.  
  303. This proposed NETRJE protocol uses a schedule verb, SCHED for job
  304. submission. For this model, there are two forms of SCHED that are
  305. relevant.  First, there is the "SCHED <server pathname>" form.  This
  306. command indicates to the server that there exists at the server site a
  307. file with all necessary job control information and data to define a
  308. job.  The server will then attempt to place the job in the job queue and
  309. reply to the user indicating success or failure and possibly a job-id.
  310. This job-id will be used when inquiring about the job status or
  311. retrieving the job's output.
  312.  
  313. When the job finishes, the server will take one of two actions:
  314.  
  315.    a)  if the user is still logged in, the server will send a reply
  316.    notifying the user of his job completion; or,
  317.  
  318.    b)  if the user is not logged in, the server will save the status of
  319.    the job which may later be interrogated via the STATUS command (see
  320.    below).
  321.  
  322. The otherform of SCHED of relevance to this model has the syntax:
  323.  
  324.    SCHED INPUT <CRLF><data><CRLF>.<CFLF>
  325.  
  326. This allows the user to sit down at a terminal and type his own job
  327. control or possibly a program.  It also allows those users whose local
  328. systems provide a facility to transmit files with User TELNET to
  329. transmit user input job fles in this way.  The RJE Server would insert
  330. the job into the local job stream, returning the proper indication of
  331. success or failure along with identification of the job.
  332.  
  333. Just as the SCHED command provides several ways for job submission, the
  334. OUTPUT command provides several options for retrieving output.  The form
  335.  
  336.  
  337.  
  338.  
  339.  
  340.  
  341.                                                                 [page 5]
  342.  
  343. NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
  344. An RJE Protocol for a Resource Sharing Network
  345.  
  346.  
  347.  
  348.    OUTPUT<job-id><server pathname>DISCARD
  349.  
  350. is sent to the server to initiate the output to the user's site
  351. according to output specifications defined by previous OUTDEF commands
  352. (see below).  The optional DISCARD argument to the OUTPUT command
  353. indicates, if present, that the file is to be destroyed after
  354. transmission has completed successfully.
  355.  
  356. The OUTDEF command for a job may be sent at any time after the job has
  357. been scheduled and before it is retrieved using the OUTPUT command.
  358. This command will specify the parameters necessary to effect the
  359. transfer of the output to the user or to define the disposition of the
  360. output.  We realize that the OUTDEF <job-id><server pathname> command
  361. (indicating that output is to be placed in a file described by the
  362. pathname) may be difficult for some systems to implement.  These systems
  363. would merely respond negatively indicating their inability to perform
  364. the function.
  365.  
  366. A scenario is now in order to illustrate the model.  The user has logged
  367. in to Multics and is ready to submit an RJE job in the following way
  368. (XXX will denote the as yet unspecified reply code for the reply):
  369.  
  370.    SCHED MY-JOB>TREK
  371.  
  372. The system responds with a reply indicating the job has been submitted
  373. successfully and returns a job-id, say XA1423.
  374.  
  375.    XXX JOB XA1423 was successfully submitted.
  376.  
  377. At some later time a message appears.
  378.  
  379.    XXX JOB XA1423 has completed.
  380.  
  381. The user or user process now sends OUTDEF XA1423 TELNET indicating that
  382. the job should be sent on the TELNET connection.  A reply returns
  383.  
  384.    XXX last command successful.
  385.  
  386. The user now sends
  387.  
  388.    OUTPUT XA1423
  389.  
  390. and the server replies with
  391.  
  392.    XXX Output ready.  Type an empty line when ready.
  393.  
  394. The user then sends an empty line when he is read to receive the output.
  395.  
  396.  
  397.  
  398.  
  399.  
  400.                                                                 [page 6]
  401.  
  402. NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
  403. An RJE Protocol for a Resource Sharing Network
  404.  
  405.  
  406.  
  407. This exchange allows the user to effect output diversion at his local
  408. site if necessary after he has confirmed the server is ready.
  409.  
  410. If the user had not wished to wait on his output and had logged off
  411. after getting the successful submission, the next time the user logged
  412. in he could inquire as to the status of the job or all jobs under his
  413. usercode and then proceeded to output any or all of them.
  414.  
  415. RJE with TELNET and Data Transfer
  416. ---------------------------------
  417.  
  418. The previous model provided a minimal implementation for NETRJE.  This
  419. model provides better data transfer facilities without requiring an FTP
  420. implementation.  This model requires no new commands, but does
  421. manipulate connections differently, so that data is not required to flow
  422. on the command connection (see Fig. 2).  Data is sent on separate
  423. default connections (unless otherwise specified) as in the CCN NETRJS
  424. protocol.  However, for this protocol the defaults used will be the same
  425. offsets from the control connection as those in FTP.
  426.  
  427. The use of this model is indicated to the Server by either the INDEF
  428. command or a SCHED command with no arguments.  The INDEF command allows
  429. the user to specify a socket other than the default socket as the source
  430. of the input.  On receipt of the SCHED or INDEF indicating this
  431. technique is to be used, the Server will attempt to connect to the
  432. appropriate socket.  If a SCHED command was sent, the user protocol
  433. interpreter could start sending cards as soon as the data connection is
  434. established.  (It is assumed that the user interface has indicated to
  435. the RJE protocol interpreter where the cards are to come from.)  If the
  436. command was INDEF, then the Server will not start reading until the
  437. SCHED is received.  Similarly, when the output is ready, either an
  438. OUTDEF or OUTPUT command is sent to set up and start the printing.  The
  439. INDEF and OUTDEF commands used with this mode will also allow moving
  440. data to or from a TIP or printer.
  441.  
  442. This model requires definiton of actual data transfer formats for the
  443. reader and printer lines.  We propose that the formats and connection
  444. schemes of the present FTP be adopted.  This solution has the advantage
  445. of not requiring extra coding efforts for users with FTP implementations
  446. and may allow them to organize their FTP implementations and may allow
  447. them to organize their FTP and NETRJE implementations in such a way as
  448. to take advantage of common algorithms.  One might easily confuse this
  449. solution with a revival of the Data Transfer Protocol.  Some thought on
  450. a more rigorous definition of a Data Transfer Protocol for the common
  451. use of FTP and RJE might be worthwhile in the future.
  452.  
  453.  
  454.  
  455.  
  456.  
  457.  
  458.  
  459.                                                                 [page 7]
  460.  
  461. NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
  462. An RJE Protocol for a Resource Sharing Network
  463.  
  464.  
  465.  
  466. Let us consider a scenario.
  467.  
  468. The user wishes to submit a card deck to the Server.  He then types
  469.  
  470.    SCHED<CRLF>
  471.  
  472. The Server opens a connection to the user's default card reader socket
  473. while sending a reply to the user on the control connection.
  474.  
  475.    XXX attempting connection to card reader.
  476.  
  477. When the connection is opened, another reply:
  478.  
  479.    XXX transfer started
  480.  
  481. and when completed:
  482.  
  483.    XXX JOB XA 1423 was successfully submitted.
  484.  
  485. When the job completes and the completion message is sent to the user,
  486. he may wish to send the output to his TIP printer on socket Y.  He will
  487. then type
  488.  
  489.    OUTDEF XA1423 255, Y (255 being his host address).
  490.  
  491. The Server will then attempt to connect to the socket and will reply
  492.  
  493.    XXX printer connection successful.
  494.  
  495. When the user has satisfied himself all is in readiness, he will type
  496.  
  497.    OUTPUT XA1423
  498.  
  499. and the Server will start sending and reply to the user
  500.  
  501.    XXX print started.
  502.  
  503. When the transfer is complete the Server will close the data connection
  504. and send an appropriate reply.
  505.  
  506.  
  507.  
  508.  
  509.  
  510.  
  511.  
  512.  
  513.  
  514.  
  515.  
  516.  
  517.  
  518.                                                                 [page 8]
  519.  
  520. NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
  521. An RJE Protocol for a Resource Sharing Network
  522.  
  523.  
  524.  
  525. NETRJE Using FTP
  526. ----------------
  527.  
  528. This model (illustrated in Fig. 3) uses FTP to effect the transfer of
  529. the files.  It may be easier for some systems to use this sort of model
  530. for more sophisticated RJE systems.  This is especially true if the
  531. users desire to take input from the local file system or to send output
  532. to the local file system rather than from an actual card reader or to an
  533. actual line printer.  Although using the local file system is not
  534. prohibited by the Data Transfer model, it may be easier to approach
  535. through FTP.  Using FTP with NETRJE also allows the utilization of the
  536. FTP server-server transfer mechanism to generate input from or direct
  537. output to a third host.
  538.  
  539. The only new facility required by this model are the commands INPATH and
  540. OUTPATH.  When using FTP to transfer input to the Server, the user must
  541. know where to send the job so that it enters the job stream.  The INPATH
  542. command returns as a reply such a legal pathname.  Thus the scenario for
  543. job submission is as follows:  The user sends an INPATH command; the
  544. Server responds with a legal Server pathname for the user.  The user
  545. process starts sending the input to the file using FTP.  When transfer
  546. is complete, the user sends a SCHED <server pathname> command.  When the
  547. job has finished, the pathname created for the user may or may not
  548. destroy the input file.  The OUTPATH command is similarily used to
  549. identify the pathname for the output, so that it may be retrieved by
  550. FTP.  Some systems may define file names in such a way that the user may
  551. derive them from the parameters of his job.
  552.  
  553. Note on Replies
  554.  
  555. In all of the above examples we have refrained from defining actual
  556. reply codes.  The intent is to use the same reply structure, and where
  557. appropriate the same numbers, as described in RFC 640 "Revised FTP Reply
  558. Codes".
  559.  
  560. Protocol Measurement
  561.  
  562. An integral part of any good protocol definition is a set of
  563. measurements to allow evaluation of both the protocol and its
  564. implementation.  This provides two functions:  1) It allows the protocol
  565. designer to evaluate the protocol and make improvements.  2) It allows
  566. the user of the protocol to know how expensive it is and to demand
  567. improvements.  The proposed NETRJE protocol provides two sets of
  568. measures - one for a particular session and one for overall performance.
  569. These measurements may be elicited by the MEASURE command which will
  570. take an argument with three values:  JOB (job statistics and cost
  571. measurements), SESSION (measurements taken for this sesson), and GLOBAL
  572.  
  573.  
  574.  
  575.  
  576.  
  577.                                                                 [page 9]
  578.  
  579. NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
  580. An RJE Protocol for a Resource Sharing Network
  581.  
  582.  
  583.  
  584. (overall measurements of the performance of the protocol and its
  585. implementation).  The command will return the measurements in a fixed
  586. format reply.
  587.  
  588. The measurements reported for a job are:
  589.  
  590.    1.  CPU time,
  591.  
  592.    2.  I/O operations,
  593.  
  594.    3.  storage space time product,
  595.  
  596.    4.  job cost in dollars,
  597.  
  598.    5.  elapsed time the job waited before being executed, and
  599.  
  600.    6.  elapsed time for the job to execute.
  601.  
  602. The measures taken from a sesson are:
  603.  
  604.    1.  number of bits transferred,
  605.  
  606.    2.  transmission rate of input or output transfers,
  607.  
  608.    3.  the amount of CPU time, storage space-time product, and I/O
  609.    operations for the session.
  610.  
  611.    4.  cost in dollars and cents.
  612.  
  613. The measures to be taken globally are:
  614.  
  615.    1.  frequency of commands and possibly command forms,
  616.  
  617.    2.  model frequency (which submission/retrieval model used),
  618.  
  619.    3.  transmission mode frequency,
  620.  
  621.    4.  total number of sessions,
  622.  
  623.    5.  transmission rate:  average, std. deviation, upper and lower
  624.    bounds (also by transmission mode),
  625.  
  626.    6.  cpu time, storage space-time product, and I/O operations for both
  627.    the protocol and jobs submitted:  average, std. deviation, and upper
  628.    and lower bounds (overall as well as by model, transfer mode, and
  629.    file size).  (The reason for including job statistics here is so that
  630.  
  631.  
  632.  
  633.  
  634.  
  635.  
  636.                                                                [page 10]
  637.  
  638. NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
  639. An RJE Protocol for a Resource Sharing Network
  640.  
  641.  
  642.  
  643.    management and systems personnel have some indication how the
  644.    facility is being used.)
  645.  
  646. It is clear that it may be difficult to acquire some measures (such as
  647. transmission rate) when NETRJE is using FTP.  This is unavoidable since
  648. FTP is not metered.  The most straightforward solution is also to meter
  649. FTP (hint).  For the final definition a close look will be given to the
  650. subset that should be required.  Comments are welcome.  However, we
  651. believe strongly that it is very important to know how a facility like
  652. this is used as well as how well it performs.
  653.  
  654.  
  655.  
  656.  
  657.  
  658.  
  659.  
  660.  
  661.  
  662.  
  663.  
  664.  
  665.  
  666.  
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674.  
  675.  
  676.  
  677.  
  678.  
  679.  
  680.  
  681.  
  682.  
  683.  
  684.  
  685.  
  686.  
  687.  
  688.  
  689.  
  690.  
  691.  
  692.  
  693.  
  694.  
  695.                                                                [page 11]
  696.  
  697. NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
  698. An RJE Protocol for a Resource Sharing Network
  699.  
  700.  
  701.  
  702. Part II.  Preliminary Definition of NETRJE Commands
  703. ---------------------------------------------------
  704.  
  705. For purposes of discussion this section gives a very preliminary
  706. definition of the NETRJE commands and their replies.  The intent is to
  707. give a brief but not exhaustive definition of each command and its major
  708. replies to give the flavor of the protocol.  We do not do this to
  709. discourage nit-picking by critics, since we may actually overlook the
  710. obvious on occasion, but merely to expedite the writing of this paper.
  711.  
  712. The reply scheme will follow the model of the revised FTP reply codes
  713. described in RFC 640.
  714.  
  715. Access Control
  716.  
  717.    USER <usercode>
  718.  
  719.    PASS <password>
  720.  
  721.    ACCT <account>
  722.  
  723. These perform the normal functions to log the user into the system.  The
  724. replies to them are the standard ones in FTP.  It was never clear why
  725. "account" was not included in the old NETRJE.  Presumably, if it's
  726. necessary for an FTP or Telnet user, it will be necessary for an RJE
  727. user.
  728.  
  729. REINIT
  730.  
  731. This command reinitializes the state of the NETRJE server process so
  732. that it is ready for a new user.  If the transfer of data is in progress
  733. for the previous user, it will be allowed to complete.
  734.  
  735. ABORT
  736.  
  737. This command is used to abort the transfer of data.  This command is
  738. meaningful to the Server only if the data is being transferred over the
  739. Telnet connection or the default data sockets.  If FTP is being used,
  740. the execution of this command is the responsibility of the USER NETRJE
  741. process.
  742.  
  743. BYE
  744.  
  745. This command causes the Server to log out the user and close the Telnet
  746. connection.  If the transfer of data is in progress, the action of the
  747. command will be delayed until the transfer is complete.
  748.  
  749.  
  750.  
  751.  
  752.  
  753.  
  754.                                                                [page 12]
  755.  
  756. NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
  757. An RJE Protocol for a Resource Sharing Network
  758.  
  759.  
  760.  
  761. SCHED <input part><output part>
  762.  
  763. <input part>::= <empty>|<server pathname> [DISCARD]
  764.  
  765.    INPUT <CRLF>   <text>   <CRLF>.<CRLF>
  766.  
  767. output part ::= <empty>|<server pathname>[DISCARD]
  768.  
  769. server pathname ::= {locally recognizable string of characters
  770. terminated by an ASCII NULL}
  771.  
  772. This command causes the input described by the <input part> to be
  773. entered into the RJE job stream and the output produced to be disposed
  774. of according to the <output part>.  The null condition for either
  775. argument implies that the information has been previously specified or
  776. is the default.
  777.  
  778. For the <input part>, the <empty> may imply two actions.  If an INDEF
  779. command has previously specified a <server pathname>, input to the job
  780. stream is taken from the file indicated by the file name.  If the INDEF
  781. command has specified that the input is to come from a CCN-like data
  782. transfer socket, the SCHED <empty> command is the signal for the Server
  783. to start reading data.
  784.  
  785. The DISCARD modifier, if present, indicates that the file should be
  786. discarded after it has been transmitted or it has been received and
  787. executed.  If the input stream is to be sent on the Telnet connection,
  788. the source may be a local device or a human user.  This facility is
  789. provided for mini-hosts that can't use one of the other techniques and
  790. for the user who wishes to enter job control directly at his terminal.
  791.  
  792. The empty for output specifies either the primary output file of the job
  793. (the default) or a previously specified server pathname (OUTDEF
  794. command).
  795.  
  796. Successful replies to this command should indicate any job-id assigned
  797. by the local RJE system along with other status informaton.  Failure
  798. would be because files did not exist, access was denied, etc.
  799.  
  800. OUTPUT <output spec>
  801.  
  802. <output spec>::= <job-id><xmsn part>|<job-id><server pathname>
  803.  
  804. <xmsn part>::= <empty>| /<IO params>
  805.  
  806. <IO params>::= <xmsn params>, <dest>
  807.  
  808.  
  809.  
  810.  
  811.  
  812.  
  813.                                                                [page 13]
  814.  
  815. NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
  816. An RJE Protocol for a Resource Sharing Network
  817.  
  818.  
  819.  
  820. This command indicates to the Server what output  is to be sent to the
  821. user, how it is to be sent, and to whom.  The <IO params> part will
  822. allow the specification of a host and socket so that output may be sent
  823. to a TIP printer, or alternatively sent on the Telnet connection or to
  824. the default data sockets.  This argument also specifies the format and
  825. representation of the data.
  826.  
  827. When the Server receives this command, it will proceed to transmit the
  828. output to the host in the prescribed manner.  The reply structure of
  829. this command will depend on how the output is moved and will be
  830. discussed in more detail later.
  831.  
  832. INPATH
  833.  
  834. This command returns to the user a legal pathname at the Server.  The
  835. user may then transfer his input to this pathname for eventual
  836. submission to the RJE facility.
  837.  
  838. OUTPATH
  839.  
  840. This command performs a similar function to INPATH.
  841.  
  842. DISCARD   <job-file-id>  |  <server pathname>
  843.  
  844. This allows the user to destroy input or output files associated with a
  845. job.
  846.  
  847. INDEF     <job-id><I/O params>
  848.  
  849. OUTDEF    <job-id><I/O params>
  850.  
  851. These commands allow the user to specify the parameters necessary to
  852. send input or retrieve output.  This command specifies how the data will
  853. be transferred and specifies format, etc.
  854.  
  855. CANCEL <job-id>
  856.  
  857. This command allows a job to be cancelled from the RJE job stream.
  858.  
  859. STATUS <status arg>
  860.  
  861. status arg ::= <empty>|<user id>|<job-id>|<job-id><blank><job-file-id>
  862.  
  863. This command allows the user to determine the status of the RJE session,
  864. all jobs under his usercode, a specific job, or the output of a specific
  865. job.
  866.  
  867.  
  868.  
  869.  
  870.  
  871.  
  872.                                                                [page 14]
  873.  
  874. NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
  875. An RJE Protocol for a Resource Sharing Network
  876.  
  877.  
  878.  
  879. ALTER <job-id><site specific option>
  880.  
  881. SITE <site specific option>
  882.  
  883. These commands allow site specific commands to be passed to the Server
  884. RJE system.  The ALTER command is intended to effect specific jobs,
  885. while the SITE command is used for commands of more global effect.  They
  886. could be merged into one.
  887.  
  888. OP <operator message>
  889.  
  890. This command allows messages to be sent to the operator at the Server
  891. site.
  892.  
  893. Reply Codes for the Proposed NETRJE
  894. -----------------------------------
  895.  
  896. The reply codes for this protocol will follow the model proposed for the
  897. new FTP specificaton in RFC 640.  As a reminder we insert the pertinent
  898. information from that RFC:
  899.  
  900. There are five values for the first digit of the reply code:
  901.  
  902. 1yz     Positive Preliminary reply
  903.  
  904.    The requested action is being initiated; expect another reply before
  905.    proceeding with a new command.  (The user-process sending another
  906.    command before the completion reply would be in violation of
  907.    protocol; but server-FTP processes should queue any commands that
  908.    arrive while a preceding command is in progress.)  For
  909.    implementations where simultaneous monitoring is difficult, this type
  910.    of reply can be used to indicate that the command was accepted and
  911.    the user-process may now pay attention to the data connections.
  912.  
  913. 2yz     Positive Completion reply
  914.  
  915.    The requested action has been successfully completed.  A new request
  916.    may be initiated.
  917.  
  918. 3yz     Positive Intermediate reply
  919.  
  920.    The command has been accepted, but the requested action is being held
  921.    in abeyance, pending receipt of further information.  The user should
  922.    send another command specifying this information.  This reply is used
  923.    in command sequence groups.
  924.  
  925.  
  926.  
  927.  
  928.  
  929.  
  930.  
  931.                                                                [page 15]
  932.  
  933. NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
  934. An RJE Protocol for a Resource Sharing Network
  935.  
  936.  
  937.  
  938. 4yz     Transient Negative Completion reply
  939.  
  940.    The command was not accepted and the requested action did not take
  941.    place, but the error condition is temporary and the action may be
  942.    requested again.  The user should return to the beginning of the
  943.    command sequence, if any.  It is difficult to assign a meaning to
  944.    "transient", particularly when two distinct sites (Server and
  945.    User-processes) have to agree on the interpretation.  Each reply in
  946.    the 4yz category might have a slightly different time value, but the
  947.    intent is that the user-process is encouraged to try again.  A rule
  948.    of thumb in determining if a reply fits into the 4yz or the 5yz
  949.    (Permanent Negative) category is that replies are 4yz if the commands
  950.    can be repeated without any change in command form or in properties
  951.    of the User or Server (e.g., the command is spelled the same with the
  952.    same arguments used, the user does not change his file access or user
  953.    name, the server does not put up a new implementation.)
  954.  
  955. 5yz     Permanent Negative Completion reply
  956.  
  957.    The command was not accepted and the requested action did not take
  958.    place.  The User-process is discouraged from repeating the exact
  959.    request (in the same sequence).  Even some "permanent" error
  960.    conditions can be corrected, so the human user may want to direct his
  961.    User-process to reinitiate the command sequence by direct action at
  962.    some point in the future (e.g., after the spelling has been changed,
  963.    or the user has altered his directory status.)
  964.  
  965. The following function groupings are encoded in the second digit:
  966.  
  967. x0z     Syntax - These replies refer to syntax errors, syntactically
  968. correct commands that don't fit any functional category, and
  969. unimplemented or superfluous commands.
  970.  
  971. x1z     Information - These are replies to requests for information,
  972. such as status or help.
  973.  
  974. x2z     Connection - Replies referring to the Telnet and data
  975. connections.
  976.  
  977. x3z     Authentication and accounting - Replies for the logon process
  978. and accountng procedures.
  979.  
  980. x4z     Unspecified as yet.
  981.  
  982. x5z     File system - These replies indicate the status of the Server
  983. file system vis-a-vis the requested transfer or other file system
  984. action.
  985.  
  986.  
  987.  
  988.  
  989.  
  990.                                                                [page 16]
  991.  
  992. NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
  993. An RJE Protocol for a Resource Sharing Network
  994.  
  995.  
  996.  
  997. The third digit gives a finer gradation of meaning in each of the
  998. function categories specified by the second digit.  The list of replies
  999. below will illustrate this.  Note that the text associated with each
  1000. reply is suggestive, rather than mandatory, and may even change
  1001. according to the command with which it is associated.  The reply codes,
  1002. on the other hand, should strictly follow the specifications.  That is,
  1003. Server implementations should not invent new codes for situations that
  1004. are only slightly different from the ones described here, but rather
  1005. should adapt codes already defined.
  1006.  
  1007. Below is a list of replies ordered by reply code.  Some new replies have
  1008. been added for RJE; these are marked by asterisks to aid the reader.
  1009. Following this list is a list of commands with the replies that are
  1010. possible for that command.  This list is not considered complete or
  1011. final; as usual comments are welcomed.
  1012.  
  1013. 110 Restart marker reply,
  1014.  
  1015.    In this case the text is exact and not left to the particular
  1016.    implementation; it must read:
  1017.  
  1018.       MARK yyyy = mmmm
  1019.  
  1020.    where yyyy is user-process data stream marker, and mmmm is Server's
  1021.    equivalent marker.  (Note the spaces between the markers and "=".)
  1022.  
  1023. 120 Service ready in nnn minutes
  1024.  
  1025. 125 Data connection already open; transfer starting
  1026.  
  1027. 150 File status okay; about to open data connection
  1028.  
  1029. 200 Command okay
  1030.  
  1031. 202 Command not implemented, superfluous at this site
  1032.  
  1033. 211 System status, or system help reply
  1034.  
  1035. 212 Directory status
  1036.  
  1037. 213 File status
  1038.  
  1039. 214 Help message (on how to use the server or the meaning of a
  1040. particular non-standard command.  This reply is useful only to the human
  1041. user.)
  1042.  
  1043. *215 RJE general status reply
  1044.  
  1045.  
  1046.  
  1047.  
  1048.  
  1049.                                                                [page 17]
  1050.  
  1051. NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
  1052. An RJE Protocol for a Resource Sharing Network
  1053.  
  1054.  
  1055.  
  1056. *216 job status reply
  1057.  
  1058. *217 RJE user's jobs status reply
  1059.  
  1060. 220 Service ready for new user
  1061.  
  1062. 221 Service closing TELNET connecton (logged off if appropriate)
  1063.  
  1064. 225 Data connection open; no transfer in progress
  1065.  
  1066. 226 Closing data connection; requested file action successful (for
  1067. example, file transfer or file abort.)
  1068.  
  1069. 227 Entering [passive, active] mode
  1070.  
  1071. 230 User logged in
  1072.  
  1073. 250 Requested file action okay, completed
  1074.  
  1075. *260 Job <job-id> has completed
  1076.  
  1077. *261 Output ready.  Type an empty line when ready
  1078.  
  1079. *262 Job <job-id> IS ALLOCATED  pathname
  1080.  
  1081. *263 Job <job-id> cancelled as requested
  1082.  
  1083. *264 Job <job-id> altered as requested to state status
  1084.  
  1085. 331 User name okay, need password
  1086.  
  1087. 332 Need account for login
  1088.  
  1089. 350 Requested file action held in abeyance, pending further information
  1090.  
  1091. 354 Start mail input; end with CRLF, CRLF
  1092.  
  1093. *360 Job <job-id> successfully submitted
  1094.  
  1095. 421 Service not available, closing Telnet connecton.  (This may be a
  1096. reply to any command if the service knows it must shut down.)
  1097.  
  1098. 425 Can't open data connection
  1099.  
  1100. 426 Connection trouble, closed; transfer aborted
  1101.  
  1102.  
  1103.  
  1104.  
  1105.  
  1106.  
  1107.  
  1108.                                                                [page 18]
  1109.  
  1110. NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
  1111. An RJE Protocol for a Resource Sharing Network
  1112.  
  1113.  
  1114.  
  1115. 450 Requested file action not taken; file unavailable (e.g., file not
  1116. found, no access)
  1117.  
  1118. 451 Requested action aborted; local error in processing
  1119.  
  1120. 452 Requested action not taken:  insufficient storage space in system
  1121.  
  1122. 500 Syntax error, command unrecognized  (This may include errors such as
  1123. command line too long.)
  1124.  
  1125. 501 Syntax error in parameters or arguments
  1126.  
  1127. 502 Command not implemented
  1128.  
  1129. 503 Bad sequence of commands
  1130.  
  1131. 504 Command not implemented for that parameter
  1132.  
  1133. 530 Not logged in
  1134.  
  1135. 532 Need account for storing files
  1136.  
  1137. 550 Requested action not taken: file unavailable (e.g., file busy)
  1138.  
  1139. 552 Requested file action aborted:  exceeded storage allocation for
  1140. current directory or dataset)
  1141.  
  1142. 553 Requested action not taken:  file name not allowed
  1143.  
  1144. *563 Job <job-id> is not known to the system
  1145.  
  1146. *564 Requested alteration is not permitted for the specified job.
  1147.  
  1148. Reply codes for RJE
  1149.  
  1150.    USER
  1151.  
  1152.       230
  1153.  
  1154.       530
  1155.  
  1156.       500, 501, 421
  1157.  
  1158.       331, 332
  1159.  
  1160.    PASS
  1161.  
  1162.  
  1163.  
  1164.  
  1165.  
  1166.  
  1167.                                                                [page 19]
  1168.  
  1169. NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
  1170. An RJE Protocol for a Resource Sharing Network
  1171.  
  1172.  
  1173.  
  1174.       230
  1175.  
  1176.       202
  1177.  
  1178.       530
  1179.  
  1180.       500, 501, 503, 421
  1181.  
  1182.       332
  1183.  
  1184.    ACCT
  1185.  
  1186.       230
  1187.  
  1188.       202
  1189.  
  1190.       530
  1191.  
  1192.       500, 501, 503, 421
  1193.  
  1194.    BYE
  1195.  
  1196.       221
  1197.  
  1198.       500
  1199.  
  1200.    REINIT
  1201.  
  1202.       120
  1203.  
  1204.       220
  1205.  
  1206.       220
  1207.  
  1208.       421
  1209.  
  1210.       500, 502
  1211.  
  1212.    ABORT
  1213.  
  1214.       225, 226
  1215.  
  1216.       500, 501, 502, 421
  1217.  
  1218.    STATUS
  1219.  
  1220.       211, 212, 213
  1221.  
  1222.  
  1223.  
  1224.  
  1225.  
  1226.                                                                [page 20]
  1227.  
  1228. NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
  1229. An RJE Protocol for a Resource Sharing Network
  1230.  
  1231.  
  1232.  
  1233.       450
  1234.  
  1235.       500, 501, 502, 421, 530
  1236.  
  1237.    HELP
  1238.  
  1239.       211, 214
  1240.  
  1241.       500, 501, 502, 421
  1242.  
  1243.    SOCK
  1244.  
  1245.       200
  1246.  
  1247.       500, 501, 421, 530
  1248.  
  1249.    BYTE, MODE, TYPE, STRU
  1250.  
  1251.       200
  1252.  
  1253.       500, 501, 504, 421, 530
  1254.  
  1255.    SCHED
  1256.  
  1257.       360     JOB <job-id> successfully submitted
  1258.  
  1259.       260     Job <job-id> has completed.
  1260.  
  1261.       125          500
  1262.  
  1263.       425, 426     501
  1264.  
  1265.       226          504, 532
  1266.  
  1267.    OUTPUT
  1268.  
  1269.       261     Output ready.  Type an empty line when ready.
  1270.  
  1271.       125     Transfer started
  1272.  
  1273.       226          500
  1274.  
  1275.       425, 426      501
  1276.  
  1277.       110
  1278.  
  1279.    OUTDEF
  1280.  
  1281.  
  1282.  
  1283.  
  1284.  
  1285.                                                                [page 21]
  1286.  
  1287. NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
  1288. An RJE Protocol for a Resource Sharing Network
  1289.  
  1290.  
  1291.  
  1292.       225     Data connection opened, no transfer in progress.
  1293.  
  1294.       425          500
  1295.  
  1296.                    501
  1297.  
  1298.                    504
  1299.  
  1300.    INDEF
  1301.  
  1302.       225          500
  1303.  
  1304.       425          501
  1305.  
  1306.                    504
  1307.  
  1308.    INPATH/OUTPATH
  1309.  
  1310.       262     JOB <job-id> IS ALLOCATED PATHNAME >
  1311.  
  1312.                    500     504
  1313.  
  1314.                     501
  1315.  
  1316.    DISCARD
  1317.  
  1318.                  250     500     530
  1319.  
  1320.                  450     501
  1321.  
  1322.                  550     502
  1323.  
  1324.                          421
  1325.  
  1326.    CANCEL
  1327.  
  1328.       263     Job <job-id> Cancelled as requested
  1329.  
  1330.                     500     504
  1331.  
  1332.                     501
  1333.  
  1334.                     502
  1335.  
  1336.       563     Job <job-id> is not known to the system
  1337.  
  1338.  
  1339.  
  1340.  
  1341.  
  1342.  
  1343.  
  1344.                                                                [page 22]
  1345.  
  1346. NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
  1347. An RJE Protocol for a Resource Sharing Network
  1348.  
  1349.  
  1350.  
  1351.       564     Requested Alteration is not permitted for the specific
  1352.       job.
  1353.  
  1354.    STATUS
  1355.  
  1356.       215     RJE general status reply
  1357.  
  1358.       216     RJE job status reply
  1359.  
  1360.       217     RJE user's jobs status reply
  1361.  
  1362.       500, 501, 502, 504
  1363.  
  1364.    ALTER
  1365.  
  1366.    
  1367.  
  1368.       264     Job <job-id> altered as requested to state status
  1369.  
  1370.       500, 501, 502, 504     563, 564
  1371.  
  1372.    SITE
  1373.  
  1374.       200
  1375.  
  1376.       500, 501, 502, 504
  1377.  
  1378.    OP
  1379.  
  1380.       200
  1381.  
  1382.       500, 501, 502, 504
  1383.  
  1384.  
  1385.  
  1386.  
  1387.  
  1388.  
  1389.  
  1390.  
  1391.  
  1392.  
  1393.  
  1394.  
  1395.  
  1396.  
  1397.  
  1398.  
  1399.  
  1400.  
  1401.  
  1402.  
  1403.                                                                [page 23]
  1404.  
  1405. NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
  1406. An RJE Protocol for a Resource Sharing Network
  1407.  
  1408.  
  1409.  
  1410. References
  1411. ----------
  1412.  
  1413. Braden, R.
  1414.  
  1415.    1971 "Interim NETRJS Specifications", RFC 189, NIC 7133.
  1416.  
  1417. Bressler, R.; Guida, R.; and McKenzie, A.
  1418.  
  1419.    1972 "Remote Job Entry Protocol", RFC 407
  1420.  
  1421. Neigus, N.
  1422.  
  1423.    1973 "The File Transfer Protocol", RFC 542.
  1424.  
  1425. Neigus, N.; Pogran, K.; and Postel, J.
  1426.  
  1427.    1974 "A New Schema for FTP Reply Codes", RFC 640.
  1428.  
  1429.  
  1430.  
  1431.  
  1432.  
  1433.  
  1434.  
  1435.  
  1436.  
  1437.  
  1438.  
  1439.  
  1440.  
  1441.  
  1442.  
  1443.  
  1444.  
  1445.  
  1446.  
  1447.  
  1448.  
  1449.  
  1450.  
  1451.  
  1452.  
  1453.  
  1454.  
  1455.  
  1456.  
  1457.  
  1458.  
  1459.  
  1460.  
  1461.  
  1462.                                                                [page 24]
  1463.  
  1464. NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
  1465. An RJE Protocol for a Resource Sharing Network
  1466.  
  1467.  
  1468.  
  1469. Figures
  1470. -------
  1471.  
  1472.    +-----------+
  1473.    !           !
  1474.    !  user     !
  1475.    !  RJE      !
  1476.    ! interface !
  1477.    !           !
  1478.    +-----------+     +--------+    Telnet Connection     +--------+
  1479.          !           !        !                          !        !
  1480.          !           ! user   !------------------------->! server !
  1481.          ------------! RJE    !                          ! RJE    !
  1482.                      ! module !<-------------------------! module !
  1483.                      !        !                          !        !
  1484.                      +--------+                          +--------+
  1485.    
  1486.       all RJE commands, replies and data on telnet connection
  1487.    
  1488.    
  1489.                          RJE Using Only Telnet
  1490.    
  1491.                                  Figure 1.
  1492.  
  1493.    +-----------+
  1494.    !  user     !
  1495.    !  RJE      !
  1496.    ! interface !
  1497.    +-----------+     +--------+     Telnet Connection      +--------+
  1498.          !           ! user   !--------------------------->! server !
  1499.          ------------! RJE    !  RJE Commands and Replies  ! RJE    !
  1500.                      ! module !<---------------------------! module !
  1501.                      +--------+                            +--------+
  1502.                          !                                     !
  1503.                      +--------+                            +--------+
  1504.                      ! data   !          RJE Data          ! data   !
  1505.                      !transfer!----------------------------!transfer!
  1506.                      +--------+                            +--------+
  1507.                         !                                      !
  1508.            User's Local File System                  Server's RJE System
  1509.            Card Readers or Line Printers
  1510.    
  1511.                  RJE Using a Separate Data Connection
  1512.    
  1513.                                  Figure 2.
  1514.  
  1515.  
  1516.  
  1517.  
  1518.  
  1519.  
  1520.  
  1521.                                                                [page 25]
  1522.  
  1523. NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
  1524. An RJE Protocol for a Resource Sharing Network
  1525.  
  1526.  
  1527.  
  1528.    +-----------+
  1529.    !  user     !
  1530.    !  RJE      !
  1531.    ! interface !
  1532.    +-----------+     +--------+     Telnet Connection      +--------+
  1533.          !           ! user   !--------------------------->! server !
  1534.          ------------! RJE    !  RJE Commands and Replies  ! RJE    !
  1535.                      ! module !<---------------------------! module !
  1536.                      +--------+                            +--------+
  1537.    
  1538.                         ! !
  1539.                      +--------+     Telnet Connection      +--------+
  1540.                      ! user   !--------------------------->! server !
  1541.                      ! FTP    !  FTP Commands and Replies  ! FTP    !
  1542.                      ! module !<---------------------------! module !
  1543.                      +--------+                            +--------+
  1544.    
  1545.                          !                                     !
  1546.                      +--------+                            +--------+
  1547.                      ! data   !          RJE Data          ! data   !
  1548.                      !transfer!----------------------------!transfer!
  1549.                      +--------+                            +--------+
  1550.                         !                                      !
  1551.            User's Local File System                  Server's File
  1552.    System
  1553.            Card Readers or Line Printers
  1554.    
  1555.                                RJE Using FTP
  1556.    
  1557.                                  Figure 3.
  1558.  
  1559.  
  1560.  
  1561.  
  1562.  
  1563.  
  1564.  
  1565.  
  1566.  
  1567.  
  1568.  
  1569.  
  1570.  
  1571.  
  1572.  
  1573.  
  1574.  
  1575.  
  1576.  
  1577.  
  1578.  
  1579.  
  1580.                                                                [page 26]